本文透過海綿寶寶世界中蟹堡王餐廳的成長歷程，來了解後端架構如何隨著業務需求擴大而演進，盡量以輕鬆的比喻來描述不同架構的特性與優勢。

1. 單體架構 (Monolithic Architecture)

階段：蟹老闆的小攤販時期

想像蟹老闆還未開設蟹堡王，只是在比奇堡經營一個小小的路邊攤：

• 一個簡單的餐車，由蟹老闆一個螃蟹負責所有工作。
• 菜色簡單，只有美味漢堡。

特點：

• 所有功能（點單、製作、收銀）都在一個小餐車內完成。
• 蟹老闆親自處理所有事務。

優點：

• 管理簡單：蟹老闆可以輕鬆把控所有細節。
• 成本低：只需要最基本的設備。

缺點：

• 擴展困難：客人增多時，蟹老闆一個螃蟹難以應付。
• 單點故障：如果蟹老闆感冒，整個攤位就無法營業。

適用場景：

• 小型專案：如個人部落格、簡單的公司官網。
• 原型開發：快速構建 MVP（最小可行產品）來驗證想法。
• 初創公司：資源有限時，用最小成本呈現核心功能。
• 學習與教學：適合新手學習完整的開發流程，如 MVC 模式的應用。

2. 主從式架構 (Master-Slave Architecture)

階段：初創期的蟹堡王

客流量穩定之後為了擴大經營，罩大家庭，於是蟹老闆開設了蟹堡王餐廳：

• 廚房（後端）：海綿寶寶負責掌廚，負責美味蟹堡的製作。
• 櫃檯（前端）：章魚哥負責接待顧客、收銀，派大星負責送餐。

特點：

• 將本來一人的工作權責拆分開來，藉此提升出餐效率，滿足更大的客流量需求。

優點：

• 職責分離：廚房專注於製作美食，前台專注於客戶服務，提升整體產能。
• 靈活性高：可以輕鬆調整櫃檯或廚房工作流程，而不影響對方。
• 並行開發：海綿寶寶可以專注改進美味蟹堡製作效率，同時章魚哥可以精進點餐體驗。

缺點：

• 效能瓶頸：隨著業務量增加，海綿寶寶的產能會漸漸到達瓶頸，並難以改善。

適用場景：

• 網頁應用開發：前端負責用戶界面，後端處理業務邏輯和資料儲存。
• 移動應用開發：App 介面為前端，服務器端 API 為後端。

3. 分散式架構 (Distributed Architecture)

階段：蟹堡王連鎖店

經營一段時間的蟹堡王在海底世界聲名大噪，為了解決供不應求，開始在各個海底城市開設分店：

• 總店：蟹老闆負責整體品牌管理和業務策略。
• 分店：每家分店都有自己的海綿寶寶（廚師）、章魚哥（收銀員）和派大星（服務生）。

特點：

• 架構複製，每家分店都能獨立運作，從採購食材到提供服務全程自主。
• 總店制定標準，但分店可以根據當地海底居民口味稍作調整（可想像成因應不同地區語言而相應調整的設計）。

優點：

• 高度自主：各分店可以靈活應對本地需求，如珊瑚城分店可以添加珊瑚粉末增添風味。
• 風險分散：一家店的問題（如遭遇大海怪襲擊）不會影響其他分店運營。

缺點：

• 管理複雜：蟹老闆需要在保持蟹堡王品牌一致性和本地化之間取得平衡。
• 資源重複：每家店都需要培訓自己的海綿寶寶，可能造成資源浪費。

適用場景：

• 大規模電商平台：不同服務（如訂單、庫存、支付）分佈在不同伺服器。
• 社交媒體應用：用戶資料、貼文、消息等功能分散處理。
• 雲端服務：如分佈式存儲系統、大數據處理平台。
• 全球化業務：在不同地理位置部署服務，提高訪問速度和可用性。

4. 事件驅動架構 (Event-Driven Architecture)

階段：現代化的蟹堡王

業務量持續的擴增，為了提高效率，蟹老闆引入了自動化系統：

特點：

• 安裝了自助點餐機，當顧客點餐後立即觸發後續事件流程（事件導向設計）。
• 各工作站（美味蟹堡、海藻薯條、珊瑚可樂）依據訂單自動進入製作流程。

優點：

• 高效率：系統自動分配訂單到不同工作站，實現並行處理，大大縮短了海底居民的等待時間。
• 模組化：易於添加新品項或調整流程，如推出限定版珍珠蟹堡時，只需更新系統設置。

缺點：

• 系統依賴：如果點餐系統被皮老闆入侵破壞，可能導致餐廳陷入混亂（仰賴消息隊列）。
• 初期投資大：由於調整架構，蟹老闆需要投入大量錢錢來升級設備，蟹老闆可能會哭哭。

適用場景：

• 即時通訊應用：處理大量實時消息和通知。
• 物聯網（IoT）系統：處理來自各種設備的事件和數據流。
• 股市交易系統：快速響應市場變化和交易請求。
• 遊戲伺服器：處理玩家的即時操作和遊戲世界的變化。

5. 微服務架構 (Microservices Architecture)

階段：蟹老闆的海底餐飲帝國

隨著蟹老闆的事業進一步擴張，發展成為老蟹海底餐飲集團：

• 主打不同類型的餐飲品牌：蟹堡王快餐、珊瑚咖啡廳、海藻沙拉吧、蝦霸健身餐廳等。
• 每個品牌都有自己的特色團隊，如海綿寶寶領導的蟹堡王團隊、蝦霸負責的海底健身餐廳等。

特點：

• 每個品牌（服務）獨立運作，專注於自己的特色。
• 蟹老闆負責整體戰略決策，各品牌經理（如海綿寶寶）負責具體運營。

優點：

• 高度專業化：每個品牌可以專注提升自己的特色，如蟹堡王專注於更完美的美味蟹堡。
• 靈活性：可以輕鬆新增或移除品牌，不影響其他業務。

缺點：

• 管理複雜：蟹老闆需要協調多個品牌，確保整體的海底風味一致性。
• 溝通挑戰：處理跨品牌的合作（如蟹堡配珊瑚咖啡的優惠活動）可能較為複雜。

適用場景：

• 大型企業應用：如 ERP 系統，模組化拆分服務（人力資源、財務、庫存等）。
• 電商平台：訂單、庫存、用戶、支付等每個核心功能都是獨立的微服務。

結語

永遠沒有一種架構是最佳的選擇。選擇合適的架構是一個動態的過程，需要根據產品生命週期的不同階段和具體需求來做出相應的決策。在產品初期，快速開發可能更為重要；而在產品成熟期，則需要為未來的擴展和複雜業務需求做好準備。

同步更新於 Medium